A managed service provider (hereinafter a MSP) is an entity, usually a business, which manages one or more computer networks that are each used by other entities (usually customers of the MSP). MSPs are advantageous when a small business desires to outsource the management of its own computer network to the MSP. In order to effectively manage one or more computer networks for each of its customers, a MSP requires an accurate view of its customer's computer networks.
Alarms may be raised spontaneously on elements or devices of the computer network at a customer site. An alarm is a notification that an undesirable condition or event has occurred or is occurring at a device. For example, an alarm may be raised if the network bandwidth available to a device falls below a specified level, or if a device on the computer network experiences a specified condition, e.g., the utilization of a processor on the device is over 90%. Alarms may be initiated using a variety of techniques, e.g. an alarm for a device may be initiated by the device itself or by another entity.
After being initiated, alarms are transmitted to the MSP for processing. An alarm may be received by the MSP at a network operations center (hereinafter a NOC). MSPs use alarms in the management of the computer network. Information contained within the alarm enables the MSP to monitor conditions at the customer site where the alarm was raised.
In order to determine which customer site is associated with each received alarm, the MSP maintains a repository that associates devices on the computer network to customer sites. Generally, devices are identified in the repository by a unique identifier, e.g., a unique IP address. When an MSP receives an alarm, the MSP examiners the IP address contained within the alarm to determine which device is associated with the alarm. Once the particular device associated with the alarm is known by the MSP, the customer site in which the alarm originated may be determined by consulting the repository.
However, a MSP may be unable to accurately determine which device is associated with the alarm. The alarm could have originated at a customer site that uses a private IP address space. In that case, the alarm will contain the private IP address of the device at the customer site associated with the alarm. For example, a SNMP trap, which is a common mechanism used to initiate an alarm, will reflect the private IP address of the device at the customer site associated with the alarm. Different customers may use the same range of private addresses. Consequently, it is possible for devices at different customer sites that are using private IP addresses to have the same private IP address, which makes it difficult for the MSP to subsequently determine which device is associated with the alarm.
In addition, in some cases, a device may not even be known to the MSP, i.e., a device may be associated with an address that is not known or recognized by the MSP. However, the MSP would still need to determine which customer site raised the alarm associated with the unknown device. In the same vein, a customer of a MSP would still prefer that all devices at the customer site (not just those devices that are known to the MSP) be monitored by the MSP.
This problem is presented to a MSP when the customer site in which the alarm originated uses Network Address Translation. Network Address Translation, or NAT, allows multiple devices within a private network to share a single public IP address (a public IP address is an IP address for a device outside of the private network in which the device resides). Consequently, if an alarm is initiated on a private network using NAT, the device signaling the alarm might not be capable of being uniquely identified based on the IP address contained within the alarm because a trap may contain either a private IP address or a public IP address for the device associated with the alarm.
In order to determine which device is associated with the alarm, a MSP is required to maintain a set of private IP addresses used by their customers that use NAT. Maintaining a set of private IP addresses for each customer that uses NAT is very resource intensive for the MSP and undesirably requires that the customer site keeps the MSP informed of the current state of their IP addressing scheme and/or the identity of the devices used at the customer site.
Because of the above problems, a MSP may be required to execute a dedicated instance of an alarm application at the NOC for each customer site. Alternatively, the MSP may attempt to either perform a device-specific lookup (which is difficult to perform because of the amount of current information that must be maintained), or avoid situations in which their customers use overlapped private IP addresses. However, there are situations when none of these options are either available or desirable, which results in the NOC being unable to unambiguously identify the originating device. As a result, it is often impossible or impracticable for the MSP to have an accurate and consistent view of a computer system.
Moreover, applications at the NOC may need additional information associated with the alarm to facilitate the processing the alarm. However, this is undesirable because identifying information associated with the alarm involves resources at the NOC and requires the associated information to be maintained by the NOC, which may be costly or resource intensive.
Accordingly, there is an unaddressed need in the art for communicating an alarm in a computer network, while avoiding the problems and difficulties associated with the current state of the art.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.